1. Field of the Invention
The present invention relates generally to a broadband wireless access communication system, and in particular, to a system and method for performing a fast handover of a mobile subscriber station, initiated by a handover request of a serving base station.
2. Description of the Related Art
Research into a 4th generation (4G) communication system, which is the next generation communication system, is currently being conducted to provide users with services having various Qualities-of-Service (QoSs) at a transfer rate of about 100 Mbps. More particularly, active research into the 4G communication system is being carried out to support high-speed services for guaranteeing mobility and QoS in a broadband wireless access (BWA) communication system, such as a wireless Local Area Network (LAN) system and a wireless Metropolitan Area Network (MAN) system. Conventional communication systems include an Institute of Electrical and Electronics Engineers (IEEE) 802.16a communication system and an IEEE 802.16e communication system.
The IEEE 802.16a and IEEE 802.16e communication systems use an Orthogonal Frequency Division Multiplexing (OFDM) scheme and/or an Orthogonal Frequency Division Multiple Access (OFDMA) scheme in order to support a broadband transmission network for a physical channel of the wireless MAN system. The IEEE 802.16a communication system considers only a state in which a subscriber station (SS) is located in a fixed position, i.e., mobility of an SS is never taken into consideration, and a unicell structure. However, the IEEE 802.16e communication system considers mobility of an SS in the IEEE 802.16a communication system, and accordingly, in the IEEE 802.16e communication system, the SS is called a mobile subscriber station (MSS).
FIG. 1 is a diagram schematically illustrating a conventional IEEE 802.16e communication system. Referring to FIG. 1, the IEEE 802.16e communication system has a multicell structure, i.e., a cell 100 and a cell 150, and includes a base station (BS) 110 managing the cell 100, a BS 140 managing the cell 150, and a plurality of MSSs 111, 113, 130, 151, and 153. Signal exchange between the base stations 110 and 140 and the MSSs 111, 113, 130, 151, and 153 is achieved using the OFDM/OFDMA scheme.
The MSS 130 is located in a boundary region of the cell 100 and the cell 150, i.e., a handover region. If the MSS 130, while exchanging signals with the BS 110, moves in the direction of the cell 150 managed by the BS 140, its serving BS changes from the BS 110 to the BS 140.
FIG. 2 is a signaling diagram illustrating a handover process initiated at the request of an MSS in a conventional IEEE 802.16e communication system. Referring to FIG. 2, a serving BS 210 transmits a Mobile Neighbor Advertisement (MOB_NBR_ADV) message to an MSS 200 in Step 211. A format of the MOB_NBR_ADV message is shown in Table 1.
TABLE 1SyntaxSizeNotesMOB_NBR_ADV_Message_Format( ) {Management Message Type = 498 bitsOperator ID24 bits Unique ID assigned to the operatorN_NEIGHBORS8 bitsFor (j=0; j<N_NEIGHBORS; j++) {Neighbor BS-ID48 bits Physical Frequency32 bits Configuration Change Count8 bitsIncremented each time the information for theassociated neighbor BS has changed.Hysteresis threshold8 bitsMAHO report period8 bitsTLV Encoded Neighbor informationVariableTLV specific}}
As shown in Table 1, the MOB_NBR_ADV message includes a plurality of information elements (IEs), i.e., a Management Message Type indicating a type of a transmission message, an Operator ID indicating a network identifier (ID), an N_NEIGHBORS indicating the number of neighbor BSs, a Neighbor BS-ID indicating IDs of the neighbor BSs, a Physical Frequency indicating a physical channel frequency of the neighbor BS, a Configuration Change Count indicating the number of changes in configuration, a Hysteresis threshold indicating hysteresis information, a MAHO (Mobile Assisted HandOver) report period indicating a period for which an average carrier-to-interference and noise ratio (CINR) value of a neighbor BS is reported, and a TLV (Type/Length/Value) Encoded Neighbor Information indicating other information related to the neighbor BS.
The MSS 200 can acquire information on neighbor BSs by receiving the MOB_NBR_ADV message. If the MSS 200 desires to scan CINRs of pilot channel signals transmitted from neighbor BSs and the serving BS 210, it transmits a Mobile Scanning Interval Allocation Request (MOB_SCN_REQ) message to the serving BS 210 in Step 213. A format of the MOB_SCN_REQ message is shown in Table 2.
TABLE 2SyntaxSizeNotesMOB_SCN_REQ_Message_Format( ) {Management Message Type = 508 bitsScan Duration12 bits Units are framesreserved4 bits}
As shown in Table 2, the MOB_SCN_REQ message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, and a Scan Duration indicating a scanning duration for which the MSS 200 desires to scan CINRs of pilot channel signals received from the neighbor BSs. Because a time at which the MSS 200 makes a scan request is not directly related to a CINR scanning operation for the pilot channel signals, a detailed description thereof will not be given herein.
Upon receiving the MOB_SCN_REQ message, the serving BS 210 includes information based on which the MSS 200 will perform scanning in a Mobile Scanning Interval Allocation Response (MOB_SCN_RSP) message with Scan Durations≠0, and transmits the MOB_SCN_RSP message to the MSS 200 in Step 215. A format of the MOB_SCN_RSP message is shown in Table 3.
TABLE 3SyntaxSizeNotesMOB_SCN_RSP_Message_Format( ) { Management Message Type = 51 8 bits CID16 bitsbasic CID of theMSS Duration12 bitsin frames Start Frame 4 bits}
As shown in Table 3, the MOB_SCN_RSP message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, a Connection ID (CID) indicating a CID of the MSS 200 that transmitted the MOB_SCN_REQ message, a Scan Duration, and a Start Frame indicating a time at which a scanning operation starts. The Scan Duration indicates a scanning duration for which the MSS 200 performs the pilot CINR scanning, and if the Scan Duration is set to ‘0’ (Scan Duration=0), it indicates that the scan request of the MSS 200 is rejected by an SS.
Upon receiving the MOB_SCN_RSP message including the scanning information, the MSS 200 performs CINR scanning on the pilot channel signals received from the serving BS 210 and neighbor BSs acquired through reception of the MOB_NBR_ADV message according to parameters, i.e., Scan Duration, included in the MOB_SCN_RSP message in Step 217.
After completing CINR scanning on the pilot channel signals received from the neighbor BSs and the serving BS 210, the MSS 200 determines if it should change its current serving BS to a new serving BS, which is different from the serving BS 210, in Step 219.
When the MSS 200 determines to changes its current serving BS, it transmits a Mobile Subscriber Station Handover Request (MOB_MSSHO_REQ) message to the serving BS 210 in Step 221. Herein, a new BS other than the serving BS to which the MSS 200 currently belongs, i.e., a possible new serving BS to which the MSS 200 will be handed over, will be referred to as a “target BS.”
A format of the MOB_MSSHO_REQ message is shown in Table 4.
TABLE 4SyntaxSizeNotesMOB_MSSHO_REQ_Message_Format( ) {  Management Message Type = 538 bits  For (j=0; j<N_Recommended; j++) {N_Recom-mended canbe derivedfrom theknown lengthof the message    Neighbor BS-ID48 bits     BS CINR mean8 bits    Service level prediction8 bits  } Estimated HO start8 bitsThe estimatedHO time shallbe the timefor therecommendedtarget BS.}
As shown in Table 4, the MOB_MSSHO_REQ message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message and the scanning results acquired by the MSS 200. In Table 4, an N_Recommended indicates the number of neighbor BSs that transmitted pilot channel signals of which CINRs are higher than or equal to a predetermined CINR, as a result of CINR scanning on the pilot channel signals from the neighbor BSs by the MSS 200. That is, the N_Recommended indicates the number of recommended neighbor BSs to which the MSS 200 can be handed over.
The MOB_MSSHO_REQ message also includes a Neighbor BS-ID indicating IDs of neighbor BSs indicated by the N_Recommended, a BS CINR mean, which indicates an average CINR for pilot channel signals from the neighbor BSs, a Service level prediction indicating a service level predicted to be provided to the MSS 200 by the neighbor BSs, and an Estimated HO start indicating a time at which the MSS 200 will start handover.
Upon receiving the MOB_MSSHO_REQ message transmitted by the MSS 200, the serving BS 210 detects a list of candidate target BSs to which the MSS 200 can be handed over, from N_Recommended information in the received MOB_MSSHO_REQ message in Step 223. Herein, the list of candidate target BSs to which the MSS 200 can be handed over will be referred to as a “candidate target BS list,” and it will be assumed in FIG. 2 that the candidate target BS list has a first target BS 220 and a second target BS 230. The candidate target BS list can also include a plurality of target BSs, in addition to the two target BSs.
The serving BS 210 transmits HO_PRE_NOTIFICATION messages to the target BSs included in the candidate target BS list, i.e., the first target BS 220 and the second target BS 230 in Steps 225 and 227. A format of the HO_PRE_NOTIFICATION message is shown in Table 5.
TABLE 5FieldSizeNotesGlobal Header152-bit For (j=0; j<Num Records; j++) { MSS unique identifier48-bit48-bit unique identifier used by MSS (asprovided by the MSS or by the I-am-host-ofmessage) Estimated Time to HO16-bitIn milliseconds, relative to the time stamp. Avalue of 0 indicates that the estimated time isunknown. Required BW 8-bitBandwidth which is required by MSS (toguarantee minimum packet data transmission) For (i=0; i<Num_SFID_Records; i++) {  SFID32-bit  For (i=0; i<Num_QoS_Records;i++) { Required QoSVariable11.13 QoS Parameter definition encodings thatin combination define anAdmittedQoSParamSet specific to the SFIC } }}Security fieldTBDA means to authenticate this message
As shown in Table 5, the HO_PRE_NOTIFICATION message includes a plurality of IEs, i.e., a Global Header which is commonly included in messages exchanged between BSs in a backbone network, an MSS ID of the MSS 200 that desires to be handed over to the first target BS 220 or the second target BS 230, an Estimated Time to HO indicating an estimated time at which the MSS 200 will start handover, a Required BW indicating information on a bandwidth for which the MSS 200 requests a target BS which will become a new serving BS, an SFID indicating an ID of a service flow that the MSS 200 is receiving, and a Required QoS indicating information on a service level for each SFID. The bandwidth (BW) and the service level (QoS) requested by the MSS 200 are equal to the predicted service level information recorded in the MOB_MSSHO_REQ message described in Table 4.
A format of the general Global Header commonly included in messages exchanged between BSs in a backbone network, like the HO_PRE_NOTIFICATION message, is shown in Table 6.
TABLE 6FieldSizeNotesMessage Type = ? 8-bitSender BS-ID48-bitBase station unique identifier (Samenumber as that broadcastedon the DL-MAP message)Target BS-ID48-bitBase station unique identifier (Samenumber as that broadcastedon the DL-MAP message)Time Stamp32-bitNumber of milliseconds sincemidnight GMT (set to 0xffffffff toignore)Num Records16-bitNumber of MSS identity records
As shown in Table 6, the Global Header includes a plurality of IEs, i.e., a Message Type indicating a type of a transmission message, a Sender BS-ID indicating a transmission BS that transmits the transmission message, a Target BS-ID indicating a reception BS that receives the transmission message, and a Num Records indicating the number of MSSs corresponding to records included in the transmission message.
Upon receiving the HO_PRE_NOTIFICATION messages from the serving BS 210, the first target BS 220 and the second target BS 230 transmit HO_PRE_NOTIFICATION_RESPONSE messages to the serving BS 210 in response to the HO_PRE_NOTIFICATION messages in Steps 229 and 231. A format of the HO_PRE_NOTIFICATION_RESPONSE message is shown in Table 7.
TABLE 7FieldSizeNotesGlobal Header152-bit For (j=0; j<NumRecords; j++) { MSS unique48-bit 48-bit unique identifier identifierused by MSS (as provided by theMSS or by the I-am-host-of message) BW Estimated8-bitBandwidth which isprovided by BS (to guaranteeminimum packet data transmission)TBD how to set this field QoS Estimated8-bitQuality of Service levelUnsolicited Grant Service (UGS)Real-time Polling Service (rtPS)Non-real-time Polling Service (nrtPS)Best Effort}Security FieldTBDA means to authenticate this message
As shown in Table 7, the HO_PRE_NOTIFICATION_RESPONSE message includes a plurality of IEs, i.e., a Global Header which is commonly included in messages exchanged between BSs in a backbone network, an MSS unique ID of the MSS 200 that desires to be handed over to the target BSs, and bandwidth and service level information for indicating a bandwidth and a service level supportable by the target BSs to which the MSS 200 is handed over.
Upon receiving the HO_PRE_NOTIFICATION_RESPONSE messages from the first target BS 220 and the second target BS 230, the serving BS 210 analyzes the HO_PRE_NOTIFICATION_RESPONSE messages received from the first target BS 220 and the second target BS 230, and selects a target BS that can optimally support the bandwidth and service level requested by the MSS 200 after handover, as a final target BS to which the MSS 200 will be handed over. For example, if it is assumed that a service level supportable by the first target BS 220 is lower than the service level requested by the MSS 200 and a service level supportable by the second target BS 230 is higher than or equal to the service level requested by the MSS 200, the serving BS 210 selects the second target BS 230 as a final target BS to which the MSS 200 will be handed over. Therefore, the serving BS 210 transmits a HO_CONFIRM message to the second target BS 230 in response to the HO_PRE_NOTIFICATION_RESPONSE message in Step 233. A format of the HO_CONFIRM message is shown in Table 8.
TABLE 8FieldSizeNotesGlobal Header152-bit For (j=0; j<NumRecords; j++) { MSS unique48-bit 48-bit universal MAC address of the identifierMSS (as provided tothe BS on the RNG-REQ message) BW Estimated8-bitBandwidth which is providedby BS (to guaranteeminimum packet data transmission)TBD how to set this field QoS Estimated8-bitQuality of Service LevelUnsolicited Grant Service (UGS)Real-time Polling Service (rtPS)Non-real-time Polling Service (nrtPS)Best Effort Service (BE)}Security fieldTBDA means to authenticate this message
As shown in Table 8, the HO_CONFIRM message includes a plurality of IEs, i.e., a Global Header which is commonly included in messages exchanged between BSs in a backbone network as described with reference to Table 6, an MSS ID of the MSS 200 that desires to be handed over to the selected target BS, and bandwidth and service level information for indicating a bandwidth and a service level supportable by the selected target BS to which the MSS 200 is handed over.
In addition, the serving BS 210 transmits a Mobile BS Handover Response (MOB_BSHO_RSP) message to the MSS 200 in response to the MOB_MSSHO_REQ message in Step 235. Herein, the MOB_BSHO_RSP message includes information on a target BS to which the MSS 200 will be handed over. A format of the MOB_BSHO_RSP message is shown in Table 9.
TABLE 9SyntaxSizeNotesMOB_BSHO_RSP_Message_Format( ) { Management Message Type = 548 bits Estimated HO time8 bits For (j=0; j<N_Recommended; j++) {Neighbor basestations shall bepresented in anorder such thatthe first presentedis the one mostrecommendedand the lastpresented is theleastrecommended.N_Recom-mended canbe derivedfrom the knownlength of themessage.  Neighbor BS-ID48 bits  service level prediction8 bits }}
As shown in Table 9, the MOB_BSHO_RSP message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, an Estimated HO time indicating an estimated time at which a handover process will start, and information on target BSs selected by the serving BS. In addition, an N_Recommended in the MOB_BSHO_RSP message indicates the number of target BSs satisfying the bandwidth and service level requested by the MSS 200, among the target BSs in the candidate target BS list. The MOB_BSHO_RSP message includes IDs for target BSs indicated by the N_Recommended, and a predicted service level supportable to the MSS 200 by the target BSs.
Although only the information on one target BS of the second target BS 230 among the target BSs existing in the candidate target BS list is finally included in the MOB_BSHO_RSP message in FIG. 2, if there are several target BSs satisfying the bandwidth and service level requested by the MSS 200 among the target BSs existing in the candidate target BS list, information on the several target BSs is included in the MOB_BSHO_RSP message.
Upon receiving the MOB_BSHO_RSP message, the MSS 200 analyzes N_Recommended information included in the received MOB_BSHO_RSP message, and selects a target BS to which it will be handed over based on the analysis result.
After selecting the target BS, the MSS 200 transmits a Mobile Handover Indication (MOB_HO_IND) message to the serving BS 210 in response to the MOB_BSHO_RSP message in Step 237. A format of the MOB_HO_IND message is shown in Table 10.
TABLE 10SyntaxSizeNotesMOB_HO_IND_Message_Format( ) { Management Message Type = 56 8 bits reserved 6 bitsReserved; shallbe set to zero HO_IND_type 2 bits00:Serving BS released01: HO cancel10: HO reject11: reserved Target_BS_ID48 bitsApplicable onlywhenHO_IND-typeis set to 00. HMAC Tuple21 bytesSee 11.4.11}
As shown in Table 10, the MOB_HO_IND message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, a HO_IND type indicating whether the MSS 200 has determined, canceled, or rejected handover to the selected final target BS, a Target_BS_ID indicating an ID of the selected final target BS when the MSS 200 determines the handover, and a HMAC (Hashed Message Authentication Code) Tuple used for authentication of the MOB_HO_IND message. The MSS 200 transmits a MOB_HO_RSP message with HO_IND_type=00 when it has determined to perform handover to the final target BS, transmits a MOB_HO_RSP message with HO_IND_type=01 when it has determined to cancel the handover to the final target BS, and transmits a MOB_HO_RSP message with HO_IND_type=10 when it has determined to reject the handover to the final target BS. Upon receiving the MOB_HO_IND message with HO_IND_type=10, the serving BS 210 updates the candidate target BS list and retransmits a MOB_BSHO_RSP message with the candidate target BS list to the MSS 200.
Upon receiving the MOB_HO_IND message with HO_IND_type=00, the serving BS 210 recognizes that the MSS 200 will perform handover to the target BS included in the MOB_HO_IND message, i.e., the second target BS 230, and releases a connection currently set up to the MSS 200 or retains the connection set up to the MSS 200 for a predetermined time until it receives a report indicating completion of the handover process from the target BS finally selected by the MSS 200, i.e., the second target BS 230, in Step 239.
After transmitting the MOB_HO_IND message to the serving BS 210, the MSS 200 performs the remaining handover operation with the second target BS 230.
FIG. 3 is a signaling diagram illustrating a handover process initiated at the request of a BS in a conventional IEEE 802.16e communication system. However, before a description of FIG. 3 is given, it should be noted that the handover initiated at the request of a BS occurs when the BS requires load sharing for dispersing its own load to neighbor BSs due to its excessive load, or when it is necessary to cope with a variation in an uplink state of an MSS.
Referring to FIG. 3, a serving BS 310 transmits a MOB_NBR_ADV message to an MSS 300 in Step 311. The MSS 300 can acquire information on neighbor BSs by receiving the MOB_NBR_ADV message.
If the serving BS 310 detects a need for handover of the MSS 300 that it is currently managing in Step 313, it transmits HO_PRE_NOTIFICATION messages to neighbor BSs in Steps 315 and 317. Herein, the HO_PRE_NOTIFICATION message includes information on a bandwidth and service level that should be supported by a target BS, which will become a new serving BS of the MSS 300. Additionally, it is assumed in FIG. 3 that the neighbor BSs of the serving BS 310 include two BSs, i.e., a first target BS 320 and a second target BS 330.
Upon receiving the HO_PRE_NOTIFICATION messages, the first target BS 320 and the second target BS 330 transmit HO_PRE_NOTIFICATION_RESPONSE messages to the serving BS 310 in response to the HO_PRE_NOTIFICATION messages, respectively, in Steps 319 and 321. The HO_PRE_NOTIFICATION_RESPONSE message includes ACK/NACK indicating if the target BSs can perform handover requested by the serving BS 310, and information on a bandwidth and service level supportable to the MSS 300.
Upon receiving the HO_PRE_NOTIFICATION_RESPONSE messages from the first target BS 320 and the second target BS 330, the serving BS 310 selects target BSs that can support the bandwidth and service level requested by the MSS 300. For example, if it is assumed that a service level supportable by the first target BS 320 is lower than the service level requested by the MSS 300 and a service level supportable by the second target BS 330 is higher than or equal to the service level requested by the MSS 300, the serving BS 310 selects the second target BS 330 as a target BS to which the MSS 300 can be handed over.
After selecting the second target BS 330 as a candidate target BS, the serving BS 310 transmits a Mobile BS Handover Request (MOB_BSHO_REQ) message including the updated candidate target BS list to the MSS 300 in Step 323. Herein, the candidate target BS list can include a plurality of target BSs. A format of the MOB_BSHO_REQ message is shown in Table 11.
TABLE 11SyntaxSizeNotesMOB_BHSO_REQ_Message_Format( ) { Management Message Type = 528 bits For (j=0; j<N_Recommended; j++) {N_Recom-mended can bederived from theknown lengthof the message  Neighbor BS-ID48 bits   Service level prediction8 bits }}
As shown in Table 11, the MOB_BSHO_REQ message includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message and information on the target BSs selected by the serving BS 310. In Table 11, an N_Recommended indicates the number of neighbor BSs selected as candidate target BSs by the serving BS 310, and the MOB_BSHO_REQ message includes a Neighbor BS-ID indicating IDs for the neighbor BSs indicated by the N_Recommended, and information on a bandwidth and service level supportable to the MSS 300 by the neighbor BSs.
Upon receiving the MOB_BSHO_REQ message, the MSS 300 recognizes that handover has been requested by the serving BS 310, and selects a final target BS to which it will perform handover, based on the N_Recommended information included in the MOB_BSHO_REQ message. Before selecting the final target BS, if the MSS 300 desires to scan CINRs of the pilot channel signals transmitted from the serving BS 310 and the neighbor BSs, the MSS 300 transmits a MOB_SCN_REQ message to the serving BS 310 in Step 325. Because a time at which the MSS 300 makes a scan request is not directly related to a CINR scanning operation for the pilot channel signals, a detailed description thereof will not be given herein.
Upon receiving the MOB_SCN_REQ message, the serving BS 310 transmits a MOB_SCN_RSP message including scanning information based on which the MSS 300 will perform scanning, to the MSS 300 in Step 327. Upon receiving the MOB_SCN_RSP message including the scanning information, the MSS 300 performs CINR scanning on the pilot channel signals received from neighbor BSs acquired through reception of the MOB_NBR_ADV message, candidate target BSs acquired through reception of the MOB_BSHO_REQ message, and the serving BS 310, according to parameters, i.e., Scan Duration, included in the MOB_SCN_RSP message, in Step 329.
After selecting its final candidate target BS, the MSS 300 transmits a Mobile MSS Handover Response (MOB_MSSHO_RSP) to the serving BS 310 in response to the MOB_BSHO_REQ message in Step 331. A format of the MOB_MSSHO_RSP message is shown in Table 12.
TABLE 12SyntaxSizeNotesMOB_MSSHO_RSP_Message_Format( ) { Management Message Type = 548 bits Estimated HO time8 bits For (j=0; j<N_Recommended; j++) {N_Recom-mended can bederived fromtheknown lengthof the message  Neighbor BS-ID48 bits   BS S/(N+1)8 bits }}
As shown in Table 12, the MOB_MSSHO_RSP includes a plurality of IEs, i.e., a Management Message Type indicating a type of a transmission message, an Estimated HO time indicating an estimated time at which the handover process will start, and information on the target BSs selected by the MSS 310. In Table 12, an N_Recommended indicates the number of neighbor BSs selected as candidate target BSs by the MSS 300, and the MOB_MSSHO_RSP message includes a Neighbor BS-ID indicating IDs for the neighbor BSs indicated by the N_Recommended, and information on a service level supportable to the MSS 300 by the neighbor BSs.
The serving BS 310 transmits a HO_CONFIRM message to the neighbor BS selected as the final target BS by the MSS 300 in response to the HO_PRE_NOTIFICATION_RESPONSE message in Step 333. After selecting the final target BS, the MSS 300 transmits a MOB_HO_IND message with HO_IND_type=00 to the serving BS 310 in Step 335.
Upon receiving the MOB_HO_IND message with HO_IND_type=00, the serving BS 310 re-recognizes that the MSS 300 will perform handover to the final target BS included in the MOB_HO_IND message, and then releases a connection currently set up to the MSS 300 or retains the connection set up to the MSS 300 for a predetermined time, until it receives a report indicating completion of the handover process from the finally selected target BS, i.e., the second target BS 330, in Step 337.
After transmitting the MOB_HO_IND message to the serving BS 310, the MSS 300 performs the remaining handover operation with the second target BS 330.
FIG. 4 is a signaling diagram illustrating a network re-entry process performed after a handover of an MSS in a conventional IEEE 802.16e communication system. Referring to FIG. 4, as an MSS 400 changes its connection to a final target BS 450, acquires downlink synchronization with the final target BS 450, and receives a downlink_MAP (DL_MAP) message from the final target BS 450 in Step 411. Herein, the DL_MAP message includes parameters related to a downlink of the final target BS 450.
Further, the MSS 400 receives an uplink_MAP (UL_MAP) message from the final target BS 450 in Step 413. The UL_MAP message includes parameters related to an uplink of the final target BS 450, and includes a Fast UL Ranging IE allocated to support fast UL ranging of the MSS 400 whose handover is being performed by the final target BS 450. The final target BS 450 allocates the Fast UL Ranging IE to the MSS 400 to minimize a possible delay caused by handover. Therefore, the MSS 400 can perform initial ranging with the final target BS 450 on a contention-free basis according to the Fast UL Ranging IE. A format of the Fast UL Ranging IE included in the UL_MAP message is shown in Table 13.
TABLE 13SyntaxSizeNotesFast_UL_ranging IE { Extended UIUC4 bits MAC address48 bits MSS MAC address as provided on the RNG_REQmessage on initial system entry UIUC4 bitsUIUC ≠ 15. A four-bit code used to define the typeof uplink access and the burst type associated withthat access. OFDM Symbol offset10 bits The offset of the OFDM symbol in which the burststarts, the offset value is defined in units of OFDMsymbols and is relevant to the Allocation Start Timefield given in the UL-MAP message. Subchannel offset6 bitsThe lowest index OFDMA subchannel used forcarrying the burst, starting from subchannel 0. No. OFDM symbols10 bits The number of OFDM symbol that are used to carrythe UL Burst No. Subchannels6 bitsThe number of OFDMA subchannels withsubsequent indexes, used to carry the burst. Reserved4 bits}
In Table 13, Fast_UL_ranging_IE( ) includes a Medium Access Control (MAC) address of an MSS that will be provided with ranging opportunity, an Uplink Interval Usage Code (UIUC) providing information on a field in which a start offset value for the Fast_UL_ranging_IE( ) is recorded, an offset of and the number of symbols in a contention-free-based ranging opportunity interval allocated to the MSS 400, and the number of subchannels. A MAC address of the MSS 400 has been reported to the final target BS 450 through messages exchanged between a serving BS and a target BS in a backbone network in the handover process described with reference to FIGS. 2 and 3, e.g., the HO_PRE_NOTIFICATION/HO_PRE_NOTIFICATION_RESPONSE/HO_CONF IRM messages.
Upon receiving the UL_MAP message, the MSS 400 transmits a Ranging Request (RNG_REQ) message to the final target BS 450 according to the Fast UL Ranging IE in Step 415. Upon receiving the RNG_REQ message, the final target BS 450 transmits a Ranging Response (RNG_RSP) message including information used for correcting frequency, time and transmission power for the ranging, to the MSS 400 in Step 417.
After completing the initial ranging, the MSS 400 and the final target BS 450 perform a re-authorization operation on the MSS 400 (MSS RE-AUTHORIZATION) in Step 419. In the re-authorization operation, if there is no change in security context exchanged between an old (or former) serving BS of the MSS 400 and the final target BS 450, the final target BS 450 uses the security context intact. A format of an MSS Information Response (MSS_INFO_RSP) message, which is a backbone network message for providing security context information of the MSS 400, is shown in Table 14.
TABLE 14FieldsSizeNotesGlobal Header152-bit For (j=0; j<Num Records; j++) { MSS unique identifier48-bit48-bit unique identifier used by MSS (as providedby the MSS or by the I-am-host-of message) N_NSIENumber of Network Service Information Elements For (k=0; k<N_NSIE; k++) {  Field Size16-bitSize, in bytes, of TLV encoded information fieldbelow  TLV encoded informationVariableTLV information as allowed on a DSA-REQ MACmessage } N_SAIENumber of Security Associated InformationElements For (k=0; k<N_SAIE; k++) {  Field Size16-bitSize, in bytes, of TLV encoded information fieldbelow  TLV encoded informationVariableTLV information as allowed on a PKM-xxx MACmessage } N_MSS_CAPNumber of MSS Capabilities For (k=0; k<N_MSS_CAP; k++) {  Field Size16-bitSize, in bytes, of TLV encoded information fieldbelow  TLV encoded informationVariableTLV information as allowed on a SBC-REQ MACmessage }}Security fieldTBDA means to authenticate this message
In Table 14, the MSS_INFO_RSP message includes ID information of an MSS registered in a serving BS, security context information such as Security Association Information for each MSS, network service information for each MSS, and capability information of each MSS.
When the re-authentication operation for the final target BS 450 and the MSS 400 is completed, the MSS 400 transmits a Registration Request (REG_REQ) message to the final target BS 450 in Step 421. The REG_REQ message includes registration information of the MSS 400. The final target BS 450 transmits a Registration Response (REG_RSP) message to the MSS 400 in response to the REG_REQ message in Step 423. Herein, the final target BS 450 can recognize the MSS 400 as an MSS that has been handed over thereto, by detecting registration information of the MSS 400 included in the REG_REQ message received from the MSS 400. Accordingly, the final target BS 450 maps connection information in the old serving BS of the MSS 400 to connection information in the final target BS 450, and transmits to the MSS 400 the REG_RSP message including TLV values based on which a service flow that can be actually provided in the final target BS can be reset. A format of the TLV including mapping information for connection setup in the serving BS and the final target BS 450 is shown in Table 15.
TABLE 15TypeLengthName(1 byte)(1 byte)Value (Variable length)New_CID2.12New CID after handover to new BSOld_CID2.22Old CID before handover to old BSConnection2.3VariableIf any of the service flowInfoparameters change, then those serviceflow parameters and CS parameterencoding TLVs that havechanged will be added.Connection_Info is a compoundTLV value that encapsulates theService Flow Parameters and the CSParameter that have changed forthe service. All the rules andsettings that apply to the parameterswhen used in the DSC-RSP message apply to the contentsencapsulated in this TLV.
In Table 15, TLV included in the REG_RSP message transmitted to the MSS 400 provides CID information used in the old serving BS, before handover of the MSS 400, and CID information to be used in the final target BS 450, after handover of the MSS 400. In addition, when the final target BS 450 provides a service that is different from the service flow provided by the old serving BS before handover, the TLV includes information on the changed service parameters.
After completing the network re-entry process with the final target BS 450, the MSS 400 performs a normal communication service through the final target BS 450 in Step 425.
As described above, in the IEEE 802.16e communication system, in a handover process initiated at the request of an MSS, the MSS determines a need for handover by measuring a change in downlink channel through a scanning process and transmits a handover request message to a serving BS. In response, the serving BS receives service level prediction information for neighbor BSs recommended by the MSS and delivers the service level prediction information back to the MSS. Then the MSS can select a final target BS based on CINRs of downlink channels from the neighbor BSs and service level information of the neighbor BSs. The CINR measurement is performed before the MSS determines handover, and a message exchange for predicting a service level supportable in a backbone network is performed after the MSS determines to handover.
However, in a handover process initiated at the request of a BS, a serving BS, after determining a need for handover, should exchange messages for service level prediction with all neighbor BSs. An MSS receiving a MOB_BSHO_REQ message including a recommended-BS list should perform a scanning operation to select a final target BS among the recommended BSs. Therefore, compared with the handover process initiated at the request of an MSS, the handover process initiated at the request of a BS performs both the service level measurement and the scanning operation after the handover is determined.
It can be expected that the number of BSs recommended by an MSS through CINR values in the handover process initiated at the request of an MSS is less than the number of BSs recommended through service level prediction in the handover process initiated at the request of a BS because a time for which the MSS performs CINR scanning on each of neighbor BSs is short. Accordingly, compared with the handover process initiated at the request of an MSS, the handover process initiated at the request of a BS requires a longer processing time.
Further, a BS sends a handover request to an MSS for several reasons, especially when the BS determines that handover of the MSS is urgent. Therefore, there is a demand for a method capable of performing a handover over a shorter time by improving the handover process initiated at the request of a BS, which requires a longer processing time compared with the handover process initiated at the request of an MSS.